Chapter 9 System Evolution
Large systems WANT long lifespan
Have to do updates
	Business changes
	Errors
	Hardware changes
	Software changes
	Competition
	Critical business assets
More spent on maintenance than development
	Spiral:
		Specify, implement, validate, operate, repeat
	Structure tends to degrade after changes
		Move to servicing, then retire
9.1 evolution processes
	No standard way that evolution goes
	Change proposal
	Analysis
		Cost benefit
	Release planning
	Release
	
	If new team, must understand first!
	Update requirements
	URGENT:
		Serious flaw
		Change environment
		Unanticipated business change
		Change in regulation
		Emergency fix: usually skimp on documentation
		(agile vs waterfall)

9.2 Legacy systems
	“if it aint broke, don’t fix it”
	COBOL 
		200 billion lines of COBOL code still running
	System hardware
	Support software
	Application software
	Application data
	Business processes
	(figure out an adaptation so the system works slightly differently)
	Can slow system
	New computers are bigger and faster
	Expensive and risky to replace
	(Y2K)
	
	Large specification rarely complete
	Processes tied to legacy
	Rules embedded in software
	
	Programming styles inconsistent
	Obsolete language
	Documentation out of date
	Maintenance degrades structure
	May be optimized 
		(may be harder to understand)
	Files can have inconsistent format
	
	Is it worth redoing the system?
		Low quality low value --- scrap
		Low quality high value --- reengineer/refactor
		High quality high value---continue
		High quality low value ---continue

	Scrap, continue, re-do, replace part, replace all, add interface….

9.3 software maintenance
	Fault repair			24%
	Environmental adaptation	19%
	Add functionality		58%

Easier to add functions during development 
	(at least PLAN for possible expansion)
	Development and maintenance are often different teams
	Less motivation to develop for easier changing
	Short term costs for long term gains
	Maintenance is not popular
	Older programs, harder
Predictions
	Number and complexity of interfaces
	Volatility of requirements
	Processes that use the system
Assessing
	Requests for change
	Time required for analysis
	Time to implement request
	Number of outstanding requests
Software re-engineering
	Improve structure and readability
		Reduced risk
		Reduced cost
	Limits to gains from re-engineering
	After a period of maintenance, good to do
Refactoring
	Changes to slow degradation
	Preventive maintenance
	Continuous